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REMARKS 

1. INTRODUCTION 

Applicant has amended claims 3-6, 8, 16, 18, 26 and 28-30, cancelled claims 1-2, 13-15, 
17 and 27 and added new claim 37. Accordingly, claims 1 - 37 are pending and under 
consideration in this application. Reconsideration and reexamination is hereby respectfully 
requested. 

2. STATEMENT OF INTERVIEW SUMMARY 

Applicant and his representative appreciate the courtesy of the telephone interview on 
October 18, 2006. Claims 1-6 were discussed along with the Cime et al. reference. No 

agreement was reached. 

3. CLAIM REJECTION UNDER 35 U.S.C. § 101 

Claims 16-25 stand rejected on the grounds that the claimed invention is directed to non- 
statutory subject matter. Applicant has amended claim 16 to recite in-part a "method of 
detecting memory leaks for a monitored application p rogram stored in a memory of and 
executing on a computer". In view of this amendment. Applicant respectfully requests 
reconsideration and withdrawal of the rejection. 

4. CLAIM REJECTION UNDER 35 U.S.C. § 102 

Claims 1-36 stand rejected under 35 U.S.C. § 102(e) as being anticipated by 
U.S. 2004/0078540 (Cime et al.). Applicant respectfully overcomes this rejection. 

Independent claim 3 recites, among other things, the step of "identifying increases in the 
peaks of the sampled allocated memory levels that are countable towards the alarm limit . . .". 

As claim 3 suggests, not every increase in the peak allocated memory level will be "counted" in 
the claimed methodology to detect a memory leak, but rather those that are "indicative of a 
memory leak". As described in the specification of the present application, many increases in 
the peak allocated memory levels occur due to program startup or due to normal memory 
allocation activity, both of which are normal and expected and are not indicative of a memory 
leak. Claim 3 further recites the step of "detecting a memory leak when countable increases in 
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peak allocated memory levels reach the alarm limit." Accordingly, there must be a countable 
number of increases that satisfies the alarm limit. Cime et al. does not teach or suggest these 
recitations. 

As an initial matter, Cime et al., as set forth in Applicant's prior response and 
incorporated herein, at most disclose a system predicated on observations of the growth pattems 

of collections of objects. Accordingly, Cirne et al. do not disclose any process satisfying claim 3 
which expressly relates to allocated memory levels, not the size of objects or collections of 
objects. 

Nonetheless, even assuming for purposes of argument only that the tracking of growth 
pattems disclosed in Cime et al. correlate with growth pattems in the amount of allocated 
memory (as contended by the Office), present claim 3, as amended, now recites specific 
limitations not taught or suggested by Cirne et al. 

Cime et al. cannot meet the recitation of "countable increases" in peak allocated memory 
since Cime et al. make no distinctions as to whether the increases ("growth") in the size of 
collections are due to normal allocation activity or whether it is due to activity indicative of a 
memory leak. Cime et al. is simply looking for the increase in size. 

For at least these reasons, claim 3, as amended, is respectfully contended to define over 
Cime et al. Reconsideration and withdrawal of the rejection is hereby respectfully requested. 

Claim 4 recites "a startup time interval" that begins with the initial execution of the 
application program and has a determined duration. Claim 4 further recites "ignoring increases 
in peak allocated memory levels that occur during the startup time interval . . . such that any 

increases . . . are not countable towards the alarm limit. " (emphasis added). 

Cirne et al. cannot meet claim 4. In this regard, the Office has cited to paragraphs [0016] 
- [0017] of Cime et al. for the proposition that purports to satisfy this feature, namely, 
"discontinuing track of newly allocated collections if no longer appear to be leaking." While 
Applicant understands the Office to be constming "discontinuing track of newly allocated 
collection" as meeting the "ignoring" step, Applicant respectfully points out that such "ignoring" 
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would be performed under the teachings of Cirne et al. after Applicant's recited startup time 
interval. Hence, Cirne et al. cannot meet this temporal aspect of claim 4. 

Nor are Applicant's startup time interval and Cirne et al.'s time-out period 
interchangeable for obviousness purposes. Applicant's "startup time interval", as positively 
recited as commencing with the initial execution of the application program, has a duration 
recited to cover noimal memory allocation activity which is not indicative of a memory leak. It 
can hence be ignored and any increases during this time are not "countable towards the alarm 
limit". It is respectfully contended that this is one more reason that Cirne et al. does not teach or 
suggest the present invention because Cirne et al. stop tracking ("ignore") memory allocation 
activity for memory leaks precisely during the time when it is most likely to detect a memory 
leak {i.e., after the startup) — all in the interest of saving overhead. 

In Cirne et al., if a monitored program does not immediately show a memory leak at the 
beginning of execution before its "time-out period" it will fall off the monitored list. This is a 
significant shortcoming of Cirne et al. relative to the present invention. 

Accordingly, Cirne et al. does not teach or suggest the limitations of claim 4, much less 
in combination with the features of claim 1 . Accordingly, claim 4 recites novel and nonobvious 
subject matter. The rejection is hereby respectfully requested to be reconsidered and withdrawn. 

Claim 5 positively recite a peak-to-peak timer feature where a second, subsequent 
increase in the peak allocated memory level is ignored "as not countable toward the alarni limit" 
when the second increase {i.e., a subsequent peak) occurs too closely in time to a first increase 
{i.e., a previous peak). The recited temporal characteristic is not indicative of a memory leak and 
is therefore is ignored in accordance with the invention. 

Cirne et al. cannot meet claim 5. Cirne et al. do not disclose any methodology or criteria 
for analysis other than a generalized statement that it is looking for "growth patterns that are 
constantly growing in size". This disclosure does not teach or suggest drawing distinctions as 
now positively claimed between increases in peak allocated memory levels that occur closely in 
time {not indicative of a memory leak) and increases in peak allocated memory levels that occur 
over much longer periods of time (which are indicative of a memory leak). 
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Accordingly, Cime et al. does not teach or suggest the limitations of claim 5, much less 
in combination with the features of claim 1. Accordingly, claim 5 recites novel and nonobvious 
subject matter. The rejection is hereby respectfully requested to be reconsidered and withdrawn. 

Claim 6 recites the step of determining a leakage rate as a function of time when the 
alarm limit has been reached. Claims 7 recites the step of producing a response when the 
leakage rate exceeds a preselected level. For the following reasons, Cime et al. cannot meet the 
limitations of these claims. 

While Cime et al. do disclose a methodology for looking at growth patterns (see Table 2 
of Cime et al. and accompany text), the disclosure at most teaches making such an assessment 
strictly based on the size of the collection irrespective of time. That is, for example, from Table 
2 of Cime et al., if a collection had not been previously tagged as potentially leaking (e.g., 
sensitivity counter is less than 3), and the sensitivity ( a user specified parameter) is 10, then the 
Table 2 specifies a growth of 5% (e.g., Growth Factor of 1.05 from Table 2) as a "threshold". 
However, this parameter only specifies how much the collection needs to have grown in size 
since the last check, expressed as a percentage of the original collection size, to be flagged as 
potentially leaking. Even repeatedly performing this does not develop a time-based leakage rate 
as a function of time, as now recited (e.g., X kilobytes per minute, as specified in paragraph 
[0030] of Applicant's published application under "8. MINIMUM_RATE_FOR_ALARM"). 

As set forth in Applicant's prior response. Applicant has carefully reviewed the cited 
paragraphs (e.g., [0016] through [0019]) and takes note that Cime et al. at most disclose only a 
comparison between a collection size and threshold (size) (i.e., is the collection size greater than 
the threshold?). The result of the comparison is a YES or a NO. Cirne et al. cannot therefore 
satisfy this limitation. 

The remaining claims not discussed above either (i) depend from one of claims 3-7 and 
thus contain all the limitations thereof, or (ii) include comparable limitations as described above. 
Accordingly, for at least the same reasons given above. Applicant respectfully contends that the 
rejections of all the claims have been overcome. 



12 of 13 



Serial No. 10/676,766 
Amendment dated 1 1/17/2006 
Reply to Office Action of 07/27/2006 



In view of the foregoing, Applicant respectfully requests reconsideration and withdrawal 

of the same. 

5. CONCLUSION 

For the foregoing reasons, all presently pending claims are now believed to be in a 
condition for allowance. Early notice of the same is hereby respectfully requested. 



Respectfully submitted, 
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